Parse rfc6532 addresses - #3130

…ing and output.

This changes the handling of some noncompliant IMAP clients, which James
would not tolerate before.

Application-layer code often assumes that addresses can be compared using
String.equalsIgnoreCase(), and some also uses regular expressions or
substring matching on addresses. This commit provides addresses to
upper-layer code in their UTF8 form, so that kind of code continues to
work.

This might also have security implications: If upper-layer code can be
confused about whether two addresses are the same, that sounds as if an
attacker could exploit the confusion. This change should block the
possibility.

RFC 6532 says we SHOULD do this and JAMES is generally very careful, so I
did this as well.

…etc.

This should not make a difference, but a sufficiently inventive attacker
might combine it with something to confuse some code...

…that domain.

…PUTF8.

…SameSessionShouldSucceed was instable

Once the server advertises UTF8=ACCEPT, angus-mail enables it and then takes
its supportsUtf8() branch in IMAPProtocol.search(), which passes a null charset
down to Argument.writeString(String) and encodes the search strings with
ASCIIUtility.getBytes() -- one truncated byte per char. "天天向上" reaches the
server as 29 29 11 0A, so the criterion is destroyed client-side before it hits
the wire and no server-side decoding can recover it. Same in angus-mail 2.0.5,
and there is no property to keep the client from enabling the capability.

Send the RFC 6855 wire form ourselves instead: UTF-8 octets in literals, plus a
quoted-string variant. These fail against consumeLiteral()'s former US-ASCII
decoding, so they cover the gap they were written for.

…a 5x slow down)

…UTF8